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1. Please describe GMSEC. What are its most important aspects? 


The Goddard Space Flight Center (GSFC) in Greenbelt, Maryland, USA is responsible for most of 
NASA’s sub-orbital and low-eartfeorbit (LEO) scientific satellites. GSFC also manages 
several missions in higher and^o^rspace orbits. Each satellite mission team has 
traditionally developed its own mrssidn control center, sometimes basing their approach on that of 
an earlier mission. NASA engineers have built great new software applications, but the use was 
limited to single missions due to integration difficulties caused by unique mission system designs. 

By 2000 it was becoming clear that budget restrictions at NASA could not support the old 
approach. In addition, commercial products were becoming more mature, satellite fleets were 
being considered, missions were talking about new operational concepts, and new development 
approaches were becoming common outside of the space industry. 

The Goddard Mission Services Evolution Center, or GMSEC, was started in 2001 to create a new 
standard approach for managing GSFC missions. Standardized approaches in the past involved 
selecting and then integrating the most appropriate set of functional tools. Assumptions were 
made that “one size fits all” and that tool changes would not be necessary for many years. 
GMSEC took a very different approach and has proven to be very successful. 

The core of the GMSEC architecture consists of a publish/subscribe message bus, standardized 
message formats, and an Applications Programming Interface (API). The API supports multiple 
operating systems, programming languages and messaging middleware products. We use a 
GMSEC-developed free middleware for low-cost development. A high capacity, robust 
middleware is used for operations and a messaging system with a very small memory footprint is 
used for on-board flight software. Software components can use the standard message formats 
or develop adapters to convert from their native formats to the GMSEC formats. We do not want 
vendors to modify their core products. Over 50 software components are now available for use 
with the GMSEC architecture. Most available commercial telemetry and command systems, 
including the GMV hifly® Satellite Control System, have been adapted to run in the GMSEC labs. 

A new level of situational awareness is realized by having all components publish keep-alive and 
status messages which are merged for display and analysis. New display tools show messages 
from across the functional areas of a control center. By requiring components to accept control 
directives over the bus, automation tools can be developed which analyze status messages and 
take appropriate actions when conditions are recognized. The GMSEC automation tools allow for 
combinations of status messages and temporal conditions to trigger multi-step actions. 

GMSEC systems have been in operations since 2005. The first three missions to use GMSEC 
each selected a different telemetry and command system and yet they selected the same 
automation and paging systems. Two selected the same trending systems. The GMSEC 
automation tools have allowed the Tropical Rainfall Mapping Mission (TRMM) to reduce the 
number of operational shifts per day. Other missions using GMSEC have operated totally “lights 
out” for periods of up to several weeks. 
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The number of components compatible with GMSEC continues to grow. The GMSEC 
architecture is planned for use on most of GSFC’s missions now under development, is 
operational or under evaluation at other NASA Centers and is being used to re-engineer older 
mission control centers and the GSFC flight dynamics system. GMSEC has allowed commercial 
products to be easily integrated with other NASA tools, has allowed in-house tools to be applied 
to many different missions, has allowed for the exchanging of software components with NASA 
and with outside organizations and has significantly reduced system integration time. 


2. Please describe some of the work of the CCSDS which you have been 
involved with. What role will standards and interoperability play in the 
future of space systems? 

CCSDS continues to be the primary source for space-ground communications standards for 
NASA missions. Most recently, I have been involved with XTCE, SLE and SM&C definition or 
planning. 

The XML Telemetry and Command Exchange (XTCE) standard is becoming the first joint 
standard between CCSDS and the Object Management Group (OMG) organizations. XTCE 
provides a standard data exchange format for master telemetry and command list information. I 
expect it to be widely accepted across commercial products. Control centers which today have a 
mix of in-house software and vendor products often need telemetry or command lists defined in 
multiple custom formats. We are moving towards XTCE as the common format for inputting the 
data into all of our tools. In addition, NASA has begun specifying its use in new proposal 
requests. 

CCSDS Space Link Extensions (SLE) will simplify the routing and distribution of science and 
engineering data directly from the remote ground stations. Multiple end-users can effectively 
subscribe to data streams of interest. Eventually, the SLE standards are to be extended to allow 
a common approach for ground terminal scheduling and configuration across NASA and non- 
NASA assets - greatly reducing the amount of custom interface software now needed for 
different NASA systems and commercial. Should Internet Protocols become widely used for 
space-ground communications, it may be possible to have the SLE routing capabilities handled 
directly by the IP communications protocol. 

The Spacecraft Monitor & Control (SM&C) effort involves defining a standard Service Oriented 
Architecture to allow space Agencies, including NASA and ESA, to have common applications 
software components and standard interfaces. NASA is increasing its effort in this area with an 
initial emphasis on the interoperability benefits it could bring. 

Overall, I feel that standards in the areas of space-ground communications and interoperability 
will continue to be critical. As more ambitious missions are deployed and international 
partnerships become the norm, the need for clear interoperability standards increases. Across 
the industry right now, however, is also a major debate about whether ground systems 
themselves should be the topic of standards. Several groups are now developing Service 
Oriented Architectures with the belief that many integration and reuse issues will be solved if 
industry matches to their approach. I don’t think we are to that point yet, and would like to see 
industry continue to advance their systems per their own business models for their own 
competitive advantages while maintaining compliance with emerging space industry 
communications and interoperability standards. 
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3. What role do GMSEC and standards play in NASA’s Exploration 
Initiative? 

NASA’s Exploration Initiative will require a wide range of space and ground assets to be deployed 
over the next twenty or more years. Many of the GMSEC concepts and lessons learned are 
being planned into the Exploration Systems, although the extent to which GMSEC will be used 
directly is not yet clear. Our Exploration teams are working on publish/subscribe concepts 
between space and ground assets and ways to increase commonality across data systems while 
avoiding vendor or product lock-in and allowing for technology advancement over many years. 
These are all areas where the GMSEC efforts are of particular value. 

Already, we have GMSEC labs established in many NASA Centers and connected over NASA 
networks to support Exploration integration testing and the evaluation of proposed standards and 
new conceptual ideas. 

Many of the CCSDS standards are being specified for Exploration, including the recent XTCE 
standard for telemetry and command lists and CFDP for file transfers. Exploration requirements 
and the use of IP will require the creation of new standards to better specify routing, delay 
tolerance, quality of service, publish/subscribe subject naming and other communications 
management attributes. With Exploration representing such a large portion of the overall NASA 
effort, I expect that approaches adopted by Exploration will spread to other NASA missions and 
then to non-NASA and non-U. S. missions and then into commercial products. 


4. What are the biggest challenges facing satellite ground systems today? 
What are the possible ways of addressing these challenges? 


\thjnjje the challenge of the past decade was to architect ground systems to simplify integration by 
creating clean external interfaces and efficient ways to meet mission-specific needs. I believe the 
industry has done a good job in this area. 


I thinkjthe next challenge is to adapt to the needs for much more efficient operations. Can the 
grbtfnd system handle everything itself and just notify us if there is a problem? Can fleet 
operations of dissimilar satellites become the norm? Can the operators configure their systems 
and add automation rules themselves? Can I split operations between the satellite experts and 
students at a local university? Can I easily transition my system from the integration-and-test 
phase into operations? Can my system interact with someone else’s system to coordinate 
activities? Can event or alarm messages include body text or attachments like e-mail does to 
keep me better informed? 


I thinly industry needs to be proactive in developing solutions to these issues. Today’s systems 
have nicer displays and more modern underlying software languages, but much of the basic 
functionality is as it was many years ago. I believe the current architectures are ready to support 
new capabilities and the user community is ready to confidently take advantage of the new 
approaches waiting to be developed. 


5. There has been a fair amount of discussion regarding the future of 
space systems and how a satellite will simply become a TCP/IP router in 
the sky. What do you think the impact of this would be on satellite ground 
systems? 
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First, using IP and space routing is not simple. There are many technical issues with time delays, 
error rates, disruptions and long-duration outages, limited bandwidth, dynamic routing based on 
relative orbital positions and the need for one-way links. All of these issues are being worked on 
and prototyped at NASA labs. Despite the challenges, IP still looks very promising. 

With an on-board network, commands could be directly routed to devices. Science and 
engineering telemetry data could be routed through the ground station to different users. 
Eventually, satellites or even a moon base could route data to other nearby or visible nodes. 

The initial impact to the ground systems may be very low. If IP is considered the packet transport 
mechanism and protocol, then a well-layered ground system architecture should have isolated 
the impacts. The contents of many of the telemetry or command packets may stay relatively 
unchanged and the processing could be the same as with today’s packetized processing. 


6. What is the role of industry in the evolution of satellite ground systems, 
in your opinion? 


Standards, users’ long-term visions and commercial product vendor innovations all work together 
to advance the state of our industry. Commercial product vendors are in the best position to 
understand the trends taking place across the wide variety of satellite operators. The vendors are 
also in position to leverage ideas from one user for the benefit of another. 

I would like to see more interaction between all user and vendor communities to openly discuss 
future directions. All groups have a vested interest in the future directions and there are many 
sharp people able to help set new directions. Actual product implementation decisions still need 
to be based on contract requirements or sound business model decisions. 

It also seems that telemetry and command systems are becoming commodities, where any of 
several vendors’ products can perform reliably. I would like to see more diversification between 
the commercial vendors. For this to happen, a company really needs to push into new areas 
such as model-based operations, automation, dynamic discovery or extensive fleet operations. 


Dan Smith 

NASA Goddard Space Flight Center (GSFC) 
Information Systems Division 
Senior Engineer, Satellite Ground Systems 


Dan Smith has nearly 30 years of experience developing satellite ground systems for 
missions as diverse as Hubble Space Telescope, NOAA’s 5-satellite GOES weather 
satellite system, and Globalstar’s constellation of commercial communications satellites. 
He joined NASA in 2001 as the project manager for the Goddard Mission Services 
Evolution Center developing a standards- and message-based ground systems 
architecture now operational on multiple GSFC missions. For the past 2 years he has also 
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been a member of a NAS A- wide team developing common data system requirements and 
specifications for the Exploration Initiative. Prior to joining NASA, Mr. Smith worked 
for major aerospace companies in the Washington, D.C. area in positions of lead 
architect, technical leader and project manager. He has a BS in Computer Science from 
the University of Maryland and an MS degree from George Washington University 
(GWU) and taught software courses at both the University of Maryland and at GWU. 
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